Most client/server applications should have a method to apply configuration settings to individual users that use the client to interact with the server. Such settings can be referred to as “per-user” settings. These settings are typically set by the system administrator for individual users. The users can be represented in an enterprise as objects in a user store. For example, in one conventional implementation, a “user object” is generated for each user in the enterprise.
Conventionally, there are a number of ways that these settings can be configured and applied on a per-user basis. One such method is the use of global policies that are pushed to individual clients and then enforced at the client level. However, this method has several disadvantages. Pushing such policies to every user is very difficult to fully solve and to manage, and can also require a software agent to facilitate the arrangement. Furthermore, since enforcement is on the client, a rogue client can be generated that completely bypasses these policies. Finally, pushing such policies across firewalls on non-enterprise devices is an exceedingly difficult problem to solve. Another method is to apply the per-user settings on the server side on every user object. This would, however, cause to a large amount of data to be applied to every user object in the enterprise and would quickly lead to a management nightmare as the number of settings increase.
Another disadvantage of the conventional approaches is that all aspects of the actual settings are shipped when the client/server system is shipped. The list of settings, the way to enforce the settings, and the way to display the settings to the administrator for modification, for example, are tightly coupled to the product code and shipped with the product. In other words, there is usually no mechanism for enhancements or additions to this setting list for the product developer after the product is shipped. Thus, if a new setting needs to be added a new version of the server would need to be shipped and all customers that need this setting would need to perform a system upgrade.
Yet another disadvantage with conventional implementations is that there is more or less no consistent way for such third party vendors to plug-in per-user settings to the server system such that the settings can be displayed to the administrator and enforced in the same way as the remaining settings that were actually shipped with the server. Consequently, the administrator will not obtain an integrated experience for managing the per-user settings for the server and third-party applications.